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(57) A context controller tor managing multitasking 
in a processor and a method of operating the same. In 
one embodiment, the context controller includes: (1) an 
event recorder that records occurrences of events and 
(2) an encoder, associated with the event recorder, that, 



in response to a software instruction, priority encodes 
bits corresponding to at least some of the events to gen- 
erate therefrom an event-dependent vector to allow the 
processor to branch as a function thereof. Vectoring is 
per-instance of the vector decode software instruction, 
not per-event or per-context. 
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Description 

Technical Field Of The Invention 

[0001] The present invention is directed, in general, 
to computer processors and, more specifically, to a con- 
text controller having event-dependent vector selection 
and a processor employing the context controller. 

Background Of The Invention 

[0002] The processors in general-purpose comput- 
ers, as well as those used as embedded controllers, are 
typically programmed to handle a plurality of tasks con- 
currently. A subset of these tasks must be performed in 
a timely manner, in response to specific, exogenous 
events, while the remainder of these tasks can be per- 
formed without stringent, real-time constraints. To han- 
dle both sets of tasks using a single data path, these 
processors require an efficient mechanism for respond- 
ing rapidly to exogenous events, while allowing non-real 
time processing to occur whenever no exogenous 
events are being handled. 

[0003] The predominant mechanism for event re- 
sponse is program interruption, which was first used in 
the mid-1 950s. For the past 40 years, the vast majority 
of processor architectures have included a program in- 
terruption facility that suspends the execution of a 
"background" task, and initiates the execution of a "fore- 
ground" task, upon occurrence of the exogenous event 
(s). Each program interruption, typically called an "inter- 
rupt," causes a reversible change to the execution state 
of the processor upon assertion (suitably synchronized 
to the processor's instruction flow) of an appropriate 
event. 

[0004] The priority interrupt, developed in the late- 
1950s, is a common enhancement to a program inter- 
ruption facility. In a processor supporting priority inter- 
rupts, discrete priorities are assigned, either statically or 
dynamically, to a plurality of event (interrupt request) 
signals. Associated with each of these signals is a 
uniquely identifiable resultant state for the reversible 
change in execution state of the processor. Each occur- 
rence of a priority interrupt selects the resultant state 
associated with the highest priority interrupt request as- 
serted at the time when the interrupt state change is in- 
itiated. 
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versible change in the program execution state of a 
processor is to save the interrupted program's execution 
address (and implicit inter-instruction status, such as 
condition codes), and to commence interrupt process- 
ing at a program address associated with the event 
causing the interruption. This program address is gen- 
erally obtained from a predetermined memory location 
known as an interrupt vector. At the end of the interrupt 
handling routine, the saved execution address (and sta- 
tus value, if any) are restored, permitting execution of 
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the interrupted program to resume at the point of inter- 
ruption. In most interrupt handling routines, it is neces- 
sary to save, and subsequently to restore, additional 
processor state to perform the operations necessary to 
5 respond to the interrupt. This additional state is primarily 
the contents of processor registers other than the pro- 
gram counter 

[0006] Saving and restoring these registers to/from a 
stack or dedicated block of memory can consume con- 
siderable amounts of time. Therefore, as integrated cir- 
cuits began reducing the cost and size of hardware reg- 
isters in the mid-1960s, some processors were 
equipped with multiple sets of registers. Selection of a 
different set of registers, either by the interrupt support 
hardware or by the interrupt handling software, allowed 
substantially faster interrupt response by eliminating the 
overhead of saving and restoring registers to/from main 
memory. 

[0007] The multiple register set concept reached its 
modern form on the IBM System/7, introduced in 1970. 
The System/7 had a dedicated, hardware-selected reg- 
ister set for each interrupt level, and reduced interrupt 
context switching time still further by including in each 
set a register to save the execution address (program 
counter value) when the level was preempted by an in- 
terrupt on a higher priority level. The result was an in- 
terrupt context switch time of 800ns and an interrupt re- 
turn time of 400ns, both of which were truly exceptional 
speeds for a 1 6-bit minicomputer built using 1 969 tech- 
nology. The System/7 also pioneered dynamic interrupt 
assignment, where the priority level used by each inter- 
rupt source was set by software, and could be changed 
during system operation. 

[0008] The ultimate generalization of this register set 
plus program counter technique was to allow events to 
initiate handling routines at their last execution address, 
rather than requiring them always to start using an in- 
terrupt vector address. For controlling I/O devices, data 
communication and network protocols, and other proc- 
esses defined in terms of communicating state ma- 
chines, this was a major benefit, because a state ma- 
chine could be implemented using the level's program 
counter both for instruction addressing and as the (im- 
plicit) state register. This not only eliminated the need 
for a separate state register, but also eliminated the 
overhead of a dispatch routine to select the appropriate 
handling routine based on the value in the state register. 
In effect, the register set plus program couniei aiciiiieu- 
ture provides direct hardware support for the "task" or 
"execution thread" concepts commonly supported by 
operating system software. 

[0009] The first machine developed with the intent to 
implement I/O control state machines using this tech- 
nique was the "Alto" experimental personal computer, 
designed in 1 972 by Charles Thacker at the Xerox Palo 
Alto Research Center. Since the early-1 970's many var- 
iations of these interrupt and context switching mecha- 
nisms have been developed for single-chip mtcrocom- 
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puters and microprocessors. However, none of these 
variations have introduced a fundamentally new mech- 
anism for rapid context switching in response to exoge- 
nous events. 

[0010] In high-performance systems it is often possi- 
ble to dedicate (one or more) processors for I/O control 
and/or external event handling. However, if implement- 
ed with similar technology to that used in the central 
processor(s) of the system, the utilization of these I/O 
processors tends to be very low. This is due to the fact 
that, for any particular circuit technology, the logic de- 
vices used to implement processor data paths operate 
significantly faster than the storage devices used to im- 
plement main memory, and both the logic and memory 
devices can support higher data bandwidths than any 
of the attached peripheral devices. 
[0011] During the 1960s, the architects of high-per- 
formance systems that required multiple I/O controllers 
developed a technique to share a single data path 
among a plurality of controller functions, even though 
those functions are logically disjoint. The technique 
used a single physical data path and instruction decoder 
to process, on a round-robin basis, the instruction 
streams of a plurality of logical processors. The only 
dedicated resource for each logical processor was the 
storage to hold its execution state (program counter and 
register values). The control circuitry allowed execution 
of a predetermined number of instructions (generally 1 ) 
for each logical processor on a sequential, cyclic basis. 
This control circuitry changed which one of the stored 
execution states was accessible to the data path be- 
tween the instruction cycles for different logical proces- 
sors. This technique was first used by Seymour Cray in 
the early 1960s to implement 10 I/O controllers (called 
peripheral processors or "PPUs") using a single, shared 
data path on the Control Data Corporation (CDC) model 
6600. 

[0012] Note that this logical processor state switching 
occurred on a strict time basis, and not in response to 
external events. Indeed, some successors to the Con- 
trol Data 6600 PPUs implemented a priority interrupt 
scheme on their logical processors. More recently this 
data path sharing technique has been applied to central 
processors, where it is called "shared resource multi- 
processing- In this case a plurality of independent in- 
struction streams, from different CPU tasks or pro- 
grams, are interleaved to decrease pipeline dependen- 
cies, thereby improving resource utilization, of a super- 
scalar data path. 

[0013] Accordingly, what is needed in the art is a way 
to configure, allocate and manage contexts that has a 
more general flexibility. 

Summary Of The Invention 

[0014] To address the above-discussed deficiencies 
of the prior art the present invention provides a context 
controller for managing multitasking in a processor and 



a method of operating the same. In one embodiment, 
the context controller includes: (1) an event recorder 
that records occurrences of events and (2) an encoder, 
associated with the event recorder, that, in response to 
5 a software instruction, priority encodes bits correspond- 
ing to at least some of the events to generate therefrom 
an event-dependent vector to allow the processor to 
branch as a function thereof. 

[0015] The present invention introduces the broad 

10 concept of providing vectored branches by generating 
an independent vector based on events and in response 
to issuance ol a software instruction with different vector 
tables usable for each such instruction. Vectoring is per- 
instance of the vector decode software instruction, not 

*5 per-event or per-context. By allowing software instruc- 
tions to initiate vector decode operations, restrictions 
that exist in hardware-mandated vector decode opera- 
tions are avoided, yielding a more flexible and powerful 
programming environment. 

20 [0016] "Context," for purposes of the present inven- 
tion, is defined as all processor state information (or any 
subset thereof, and such as register values) that would 
be of use in restoring the processor to a given state. An 
"event" is defined as a stimulus capable of causing the 

25 context controller to respond by switching from one fore- 
ground task to another. An exogenous event has its gen- 
esis outside the processor and can occur at any time. 
An endogenous event has its genesis inside the proc- 
essor and is synchronized with the processor's clock. In 

30 an embodiment to be illustrated and described, all 
events are recorded, but only those relevant to the cur- 
rently-active context are acknowledged. Preferably, the 
currently-active context can control which events are ac- 
knowledged and which are (at least temporarily) ig- 

35 nored. In one embodiment of the present invention, the 
encoder also generates the event-dependent vector 
from a selected one of: (1) address information in the 
software instruction and (2) address information in a 
register of the processor. Those skilled in the art will rec- 

40 ognize, however, that a vector may be constructed from 
data derived from many possible sources. The present 
invention is not limited to one or more particular sources. 
[0017] In one embodiment of the present invention, 
the context controller further includes an event masker, 

45 associated with the event recorder and the encoder, that 
masks ones of the events to yield the at least some of 
the events. Event masking may therelore optionally be 
employed to reduce the number of events factored into 
encoding and vector generation. Those skilled in the art 

50 may perceive other ways to effect selectivity that are, 
nonetheless, within the broad scope of the present in- 
vention. 

[0018] In one embodiment of the present invention, 
the event-dependent vector is selected from the group 
55 consisting of: (1) a direct branch and (2) an indirect 
branch. Those skilled in the art are familiar with various 
well-known addressing schemes, all ol which being 
within the broad scope of the present invention. 
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[0019] In one embodiment of the present invention, 
the event recorder is embodied in at least one flip-flop 
within the context controller. Of course, the event re- 
corder can be located in a register or other memory lo- 
cation. 

[0020] In one embodiment of the present invention, 
the context controller further includes: (1) a foreground 
task controller that activates contexts corresponding to 
foreground tasks based on priority and in response to 
the events and (2) a background task controller that cy- 
clicly switches among contexts corresponding to the 
background tasks subject to activation of the contexts 
corresponding to the foreground tasks. Thus, the 
present invention may be employed with a novel context 
control architecture in which tasks are divided into fore- 
ground and background tasks and allocated processor 
resources to the foreground and background tasks us- 
ing substantially different criteria. Events (to be defined 
below) may be employed to determine when foreground 
tasks are activated. In contrast, background tasks may 
be activated cyclically (based on time slice, instruction 
slice or any other cyclic allocation). Foreground tasks 
may still override background tasks, allowing the fore- 
ground tasks to handle events in a timely manner. Rel- 
ative priorities may be established between or among 
foreground tasks to assist in the allocation of processor 
resources in cases where a plurality of foreground tasks 
are active simultaneously. 

[0021] In one embodiment of the present invention, 
the context controller further includes a background task 
controller that switches among contexts corresponding 
to background tasks based on numbers of instructions 
executed by each of the background tasks. This is re- 
ferred to herein as "instruction slice. " Activation of con- 
texts can alternatively be based on time ("time slice"). 
Of course, other bases for cyclic activation are within 
the broad scope of the present invention. 
[0022] The foregoing has outlined, rather broadly, 
preferred and alternative features of the present inven- 
tion so that those skilled in the art may better understand 
the detailed description of the invention that follows. Ad- 
ditional features of the invention will be described here- 
inafter that form the subject of the claims of the inven- 
tion. Those skilled in the art should appreciate that they 
can readily use the disclosed conception and specific 
embodiment as a basis for designing or modifying other 
structures for carrying out the same purposes of the 
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realize that such equivalent constructions do not depart 
from the spirit and scope of the invention in its broadest 
form. 

Brief Description Of The Drawings 

[0023] For a more complete understanding of the 55 
present invention, reference is now made to the follow- 
ing descriptions taken in conjunction with the accompa- 
nying drawings, in which: 



FIGURE 1 illustrates a state transition diagram 
showing operation of one embodiment of a proces- 
sor of the present invention from the point of view 
of an individual context; 



FIGURE 11 illustrates field and bit assignments of 
machine instructions pertaining to context control 
and inter-context communication in the instruction 
set according to one embodiment of the present in- 
vention; 

FIGURE 12 illustrates sources of bits used to gen- 
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FIGURE 2 illustrates a diagram exemplifying possi- 
ble processing flow, preemption, and inter-context 
communication on a processor operating with five 
foreground contexts and three background con- 
10 texts; 

FIGURE 3 illustrates exemplary per-context control 
and status registers accessible to software execut- 
ing in a processor employing an embodiment of the 
15 present invention; 

FIGURE 4 illustrates a system diagram of a typical 
processor or I/O controller incorporating an embod- 
iment of the context controller of the present inven- 
20 tion; 

FIGURE 5 illustrates an interaction diagram show- 
ing an internal structure of the context controller il- 
lustrated in FIGURE 4; 

25 

FIGURE 6 illustrates a process diagram of an event 
synchronization process illustrated in FIGURE 5; 

FIGURES 7A, 7B, 7C and 7D collectively illustrate 
30 process diagrams of the event prioritization process 
illustrated in FIGURE 5; 

FIGURE 8 illustrates a timing diagram for a context 
switch controlled by the present invention in which 
35 a current context's state is stored into, and the next 
context's state is loaded from, synchronous (self- 
timed) SRAM or register files; 

FIGURE 9 illustrates a timing diagram for a context 
40 switch controlled by the present invention where a 
current context's state is stored into, and the next 
context's state is loaded from asynchronous SRAM 
or register files; 

45 FIGURE 10 illustrates a schematic diagram of one 
embodiment of a circuit suitable for implementing 
event recording, event masking and event acknowl- 
edgment lor each activation event, as vveli as man- 
agement of a context activity bit, including initializa- 
s ° tion request and wait request logic; 
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erate control store addresses on the processor ac- 
cording to one embodiment of the present inven- 
tion; 

FIGURE 13 illustrates an exemplary data structure 
diagram for initialization vectors in control store ac- 
cording to one embodiment of the present inven- 
tion; and 

FIGURE 14 illustrates a diagram setting forth target 
address generation by vector instruction used to pri- 
oritize and decode specific context activation bits 
on the processor according to one embodiment of 
the present invention. 

Detailed Description 

[0024] Referring initially to FIGURE 1 , illustrated is a 
state transition diagram showing operation of one em- 
bodiment of a processor of the present invention from 
the point of view of an individual context. The present 
invention provides a context controller for managing 
multitasking in a processor and a method of operating 
the same. In one embodiment, the context controller in- 
cludes an event recorder that records occurrences of 
events and an encoder, associated with the event re- 
corder, that, in response to a software instruction, prior- 
ity encodes bits corresponding to at least some of the 
events to generate therefrom an event-dependent vec- 
tortoallowtheprocessortobranch asafunction thereof. 
[0025] The present invention therefore introduces the 
broad concept of providing vectored branches by gen- 
erating a vector based on events and in response to is- 
suance of a software instruction. By allowing software 
instructions to initiate vector decode operations, restric- 
tions that exist in hardware -man dated vector decode 
operations are avoided, yielding a more flexible and 
powerful programming environment. 
[0026] "Context," for purposes of the present inven- 
tion, is defined as all processor state information (or any 
subset thereof, and such as register values) that would 
be of use in restoring the processor to a given state. An 
"event" is defined as a stimulus capable of causing the 
context controller to respond by switching from one fore- 
ground task to another. An exogenous event has its gen- 
esis outside the processor and can occur at any time. 
An endogenous event has its genesis inside the proc- 
essor and is synchronized with the processor's clock. In 
an embodiment to be illustrated and described, all 
events are recorded, but only those relevant to the cur- 
rently-active context are acknowledged. Preferably, the 
currently-active context can control which events are ac- 
knowledged and which are (at least temporarily) ig- 
nored. 

[0027] In one embodiment of the present invention, 
the encoder also generates the event-dependent vector 
from a selected one of address information in the soft- 
ware instruction and address information in the software 



instruction and address information in a register of the 
processor. Those skilled in the art will recognize, how- 
ever, that a vector may be constructed from data derived 
from many possible sources. The present invention is 

5 not limited to one or more particular sources. 

[0028] In one embodiment of the present invention, 
the context controller further includes a foreground task 
controller that activates contexts corresponding to fore- 
ground tasks based on priority and in response to the 

10 events and a background task controller that cyclicly 
switches among contexts corresponding to the back- 
ground tasks subject to activation of the contexts corre- 
sponding to the foreground tasks. Thus, the present in- 
vention may be employed with a novel context control 

15 architecture in which tasks are divided into foreground 
and background tasks and allocated processor resourc- 
es to the foreground and background tasks using sub- 
stantially different criteria. Events may be employed to 
determine when foreground tasks are activated. In con- 

20 trast, background tasks may be sequenced cyclically 
(based on time slice, instruction slice or any other cyclic 
allocation). Foreground tasks may still override back- 
ground tasks, allowing the foreground tasks to handle 
events in a timely manner. Relative priorities may be es- 

2S tablished between or among foreground tasks to assist 
in the allocation of processor resources when a plurality 
of foreground tasks are active simultaneously. 
[0029] At any given time that the processor is operat- 
ing, each context is in one of six states, which are logi- 

30 cally grouped into four sets as a two rows by two col- 
umns (2x2) matrix. The top or foreground row 10 con- 
tains three states: an Rf state 1 8, a Pf state 20 and a Wf 
state 22 (where each includes an T to indicate fore- 
ground) used by foreground contexts. The bottom or 

35 background row 12 contains three states: an Rb state 
24, a Qb state 26 and a Wb state 28 (where each in- 
cludes a "b" to indicate background) used by back- 
ground contexts. The active column 1 4 contains the four 
states 18, 20, 24, 26 used by the active contexts, while 

40 the inactive column 1 6 contains the two states 22 and 
26 used by the inactive contexts, respectively. 
[0030] The foreground row 10 states may be further 
defined as Rf 18 (running, foreground), Pf 20 (preempt- 
ed, foreground) and Wf 22 (waiting, foreground). The 

45 background row 1 2 states may be further defined as Rb 
24 (running, background), Qb 26 (queued, background) 
and Wb 28 (waiting, background). During each instruc- 
tion cycle, only one context may be "running" (executing 
an instruction on the processor), or the processor alter- 

50 natively may be idle. If occupied, the running context is 
the sole context in the foreground running state Rf . Or 
if the state Rf 18 is unoccupied, the running context is 
the sole context in the background running state Rb 24 
(if occupied). The execution states of contexts are gen - 

55 erally stored in separate register sets. 

[0031] Most context transitions are allowed to take 
place within either the foreground row 10 or the back- 
ground row 12, because inter-row transitions are only 



BNSDOCID: <EP _0942369A2J_> 



5 



9 

needed when a context switches between foreground 
and background operating tasks which may be distin- 
guished by a software switch operation. However, this 
occurs less frequently than context activation, preemp- 
tion and waiting. Transitions from foreground to back- 
ground may only occur when the running foreground 
context Rf 18 executes a CLRFG ("clear foreground") 
function 34, which results in a transition from the fore- 
ground running state Rf 18 to the background queued 
state Qb 26. Because there are no relative priority dis- 
tinctions among background contexts, the position in the 
background queue given to the context executing the 
CLRFG function 34 is arbitrary. 

[0032] A context executing a CLRFG function 34 is 
leaving foreground operation and advantageously relin- 
quishes control of the processor for a minimum of one 
instruction cycle (as does a context executing a WAIT 
function 32 or 42). If a lower priority foreground context 
is in the preempted state Pf 20, that lower priority fore- 
ground context runs next (via a HIGHEST PRIORITY 
transition 36). If the preempted state Pf 20 is unoccu- 
pied, a preempted context already in the background 
state Rb 24 runs next, unless the background state Rb 
24 is also unoccupied. In this case, the context at the 
head of the background queue in the background 
queued state Qb 26 runs next, via a TIME SLICE starts 
transition 44. In the illustrated embodiment, this occurs 
after a single instruction cycle with the processor idle, 
since both the foreground running state Rf 18 and the 
background running state Rb 24 are unoccupied. 
[0033] A transition between background and fore- 
ground normally occurs when a context in background 
running state Rb 24 executes a SETFG ("set fore- 
ground") function 30, which results in its transition from 
the background running state Rb 24 to the foreground 
running state Rf 18. Foreground activation of a particular 
context may also occur by vectoring to a software-se- 
lectable location. 

[0034] To prevent erroneous disruption of context op- 
eration, the functions available in the context controller 
advantageously do not include a mechanism by which 
a running context can change the foreground or back- 
ground setting of any other context without also forcing 
an initialization (INIT) of that context. The I NIT function 
may be executed by the running context with any other 
context as the target. An I NIT function can be executed 
to the running context, but no reason exists to do so un- 
less a particular embodiment attached auuiiioncii initial- 
ization side effects to the INIT function. Execution of an 
INIT function leaves the target context in the foreground 
preempted state Pf 20 with its program counter set to a 
predetermined initialization vector address, as will be 
discussed in greater detail below. 
[0035] Normally, the target of an I NIT function resides 
in the foreground wait state Wf 22 and enters the fore- 
ground preempted state Pf 20 via a transition 40. Or, it 
may reside in the background wait state Wb 28 and en- 
ter the foreground preempted state Pf 20, switching from 
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background to foreground via a transition 50. In fact, the 
transition 50 is also possible and equivalent, if the target 
context resides in either the background running state 
Rb 24 or the background queued state Qb 26, but FIG- 

5 URE 1 does not illustrate these two cases. 

[0036] At the end of a processor reset, all contexts are 
in the foreground wait state Wf 22, except the lowest- 
priority context, which is in the foreground running state 
Rf 18. Software executing on the context foreground 

10 running state Rf 1 8 may initiate a trans it ion tothe context 
foreground waiting state Wf 22 by executing a WAIT 
function 32. A foreground waiting state Wf 22 context 
transitions to the foreground preempted state Pf 20 with 
an assertion of any of that context's activation events 

is that are enabled by the context's event mask or when 
the running context executes an INIT function to this 
context foreground preempted state Pf 20 via the tran- 
sition 40. 

[0037] In the illustrated embodiment, a preemption 
20 context switch may occurs at the end of every instruction 
cycle, with the highest priority context in the foreground 
preempted state Pf 20, if any, entering the foreground 
running state Rf 18 via the HIGHEST PRIORITY transi- 
tion 36, and the previous context in the foreground run- 
2S ning state Rf 1 8, if any, entering the foreground preempt- 
ed state Pf 20 via a HIGHER PRIORITY ACTIVE tran- 
sition 38. 

[0038] Software executing in the context background 
running state Rb 24 may initiate a transition to the back- 

30 ground waiting state Wb 28 by executing a WAIT func- 
tion 42. A context in the background waiting state Wb 
28 transitions to the background queued state Qb 26 
with the assertion of any of that context's activation 
events that are enabled by the context's event mask. In 

35 one embodiment of the present invention, the context 
controller further includes an event masker, associated 
with the event recorder and the encoder, that masks 
ones of the events to yield the at least some of the 
events. Event masking may therefore optionally be em- 

40 ployed to reduce the number of events factored into en- 
coding and vector generation. Those skilled in the art 
may perceive other ways to effect selectivity that are, 
nonetheless, within the broad scope of the present in- 
vention. 

45 [0039] Transitions from the background queued state 
Qb 26 to the background running state Rb 24 may only 
occur when no foreground context is running (no context 
in siaie Rf 16). in this case, ihe running context it any, 
is in the background running state Rb 24, or the proc- 

50 essor is in an idle state because no context is ready to 
run in either foreground or background. 
[0040] At the end of every instruction cycle, with the 
context running in the background state Rb 24, the time 
slice count is decremented, and on the instruction cycle 

55 when the count reaches zero, a time slice context switch 
preferably occurs. At this point, the context at the head 
of the background queue enters the background running 
state Rb 24 via the transition 44, and the context previ- 
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ously in the background running state Rb 24 enters the 
background queued state Qb 26 via the transition 46. 
[0041] Generally, the background queued contexts 
are organized in a first-in, first-out (FIFO) arrangement 
with "wrap-around" occurring from the highest context 
number to the lowest context number when a previous- 
ly-running background context enters the background 
queued state Qb 26. It should be noted that foreground 
preemption involves a state transition via the transition 
36, whereas background preemption by foreground 
does not. In this case, the previously-running back- 
ground context remains in the state Rb 24 until the fore- 
ground running state Rf 18 is again unoccupied and a 
background context is able to run. 
[0042] Turning now to FIGURE 2, illustrated is a dia- 
gram exemplifying possible processing flow, preemp- 
tion and inter-context communication on a processor 
operating with five foreground contexts and three back- 
ground contexts. A context may be activated by the as- 
sertion of an event signal. In one embodiment of the 
present invention, the context controller further includes 
a background task controller that activates contexts cor- 
responding to background tasks based on numbers of 
instructions executed by each of the background tasks. 
This is referred to herein as "instruction slice. "Activation 
of contexts can alternatively be based on time ("time 
slice"). Of course, other bases for cyclic activation are 
within the broad scope of the present invention. 
[0043] Associated with each context may be zero or 
more exogenous event signals and zero or more endog- 
enous event signals. The principal difference between 
exogenous and endogenous event signals is that exog- 
enous signals are advantageously synchronized to the 
processor's clock before being used for context activa- 
tion decisions within the context controller. In contrast, 
endogenous signals are assumed to be generated in 
synchronism with the processor's clock and are used 
directly. 

[0044] Each of the context's activation events may be 
enabled and disabled under software control by setting 
and clearing bits in a context-specific event mask reg- 
ister. In addition to assertion of activation events due to 
the assertion of hardware signals from exogenous 
sources, such as external interlaces, or from endog- 
enous sources, such as interval timers, coprocessors or 
data transfer logic, some or all events may be asserted 
by software using signal instructions that specify a target 
context number and event number within the set of 
events associated with the target context. Since any 
context can signal events to itself or to other contexts, 
this allows the illustrated embodiment to serve as an ef- 
ficient mechanism for both intra-context and inter-con- 
text communication as well as serving as a priority in- 
terrupt controller and as a time slice controller. 
[0045] In the diagram of FIGURE 2, the vertical axis 
represents contexts, while the horizontal axis repre- 
sents context activities for each of the eight contexts 
supported on the exemplary context controller. The hor- 



izontal axis is time, in units of instruction execution cy- 
cles The wide black lines, for foreground contexts, and 
the wide cross-hatched lines, for background contexts, 
show the running context. Vertical lines with arrows 

5 show the context switches and are labeled to identify 
the reason that a context switch occurred. The small 
perpendicular lines crossing the wide lines indicate in- 
struction cycles. The numbers above each instruction 
cycle interval for background contexts is the value of the 

10 time slice instruction counter when that instruction is be- 
ing executed. Narrow dashed black lines, for foreground 
contexts, and narrow cross-hatched dashed lines, for 
background contexts, show active preempted contexts. 
Narrow dotted lines show active, queued background 

15 contexts. This embodiment has eight contexts, desig- 
nated context 0 (the highest priority) through context 7 
(the lowest priority ) : and during this example is operat- 
ing with a time slice instruction count of eight. 
[0046] At the time this example starts, contexts 0, 2, 

20 4 and 5 are all inactive foreground contexts (state Wf). 
Contexts 3, 6 and 7 are all background contexts with 
context 3 inactive (state Wb), context 7 queued (state 
Qb) and context 6 running (state Rb). 
[0047] Context 1 is inactive, and has an unknown (or 

25 indeterminate) foreground/background setting. A first 
instruction cycle 46 shown is executed by background 
context 6 as its time slice count value decrements to two. 
In a next instruction cycle 47, background context 6 ex- 
ecutes a SIGNAL function to background context 3. As 

30 a result, background context 3 becomes active entering 
state Qb on the following instruction cycle. After sending 
the SIGNAL function, background context 6 executes 
another instruction cycle 48 as its time slice count dec- 
rements to 0. This causes a context switch to the next 

35 highest context number in the active context back- 
ground queued state Qb, which is background context 
7. Context 6 enters the Qb state and context 7 enters 
the Rb state at an instruction cycle 50 with a time slice 
count value of 7. After context 7 has executed three in- 

40 structions, an exogenous event activates foreground 
context 4. Therefore, at the end of a next instruction cy- 
cle 52, background context 7 is preempted by fore- 
ground context 4 with its time slice count value remain- 
ing at four during the preemption. 

45 [0048] Foreground context 4 executes its first instruc- 
tion while an exogenous event activates foreground 
context 2. Therefore, at the end of a next instruction cy- 
cle 54, foreground context 4 is preempted by foreground 
context 2 (at a preemption point 53) entering the 

so preempted state Pf while foreground context 2 enters 
the running state Rf. After executing two instructions to 
handle its activation event, foreground context 2 exe- 
cutes a WAIT function during a third instruction cycle 56. 
This WAIT function clears the activity flip-flop for fore- 

55 ground context 2, and after one more instruction cycle, 
foreground context 2 becomes inactive reverting to the 
waiting state Wf . This allows the preempted foreground 
context 4 to return to the running state Rf and execute 
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another instruction cycle 58. Because foreground con- 
text 4 had already executed its own WAIT function prior 
to the preemption point 53, this is the final instruction 
executed by foreground context 4 before reverting to the 
waiting state Wf and permitting preempted background 
context 7 to resume running at an instruction cycle 60. 
After executing four more instructions, background con- 
text 7 completes its time slice 62, resulting in a context 
switch to the next top Qb context which is background 
context 3 because of a wrap-around of context numbers 
from context 7 to context 0. 

[0049] During the same instruction cycle 64, the back- 
ground context 3 executes the first instruction of its time 
slice 7, an exogenous event 66 activates foreground 
context 0. Therefore, at the end of this instruction cycle 
64, background context 3 is preempted by foreground 
context 0 with its time slice count value remaining at sev- 
en during the preemption. After executing three instruc- 
tions to handle its activation event, foreground context 
0 executes a WAIT function during a fourth instruction 
cycle 69. This WAIT function clears the activity flip-flop 
for foreground context 0, and after one more instruction 
cycle foreground context 0 becomes inactive, reverting 
to the waiting state Wf. This normally allows the 
preempted background context 3to resume running, but 
in this example an exogenous event 68 has activated 
foreground context 5 while foreground context 0 was 
running. Note that this activation changed the state of 
foreground context 5 from the waiting state Wf to the 
preempted state Pf, showing how it is possible for a fore- 
ground context to enter preempted state without having 
executed any instructions since activation. 
[0050] If background context 3 had been operating in 
foreground, the fact that foreground context 5 was in the 
preempted state Pf when foreground context 0 reverted 
to the waiting state Wf would be irrelevant, since back- 
ground context 3 is higher in priority than foreground 
context 5. However, context 3 is operating in back- 
ground, so a WAIT function 69 executed by foreground 
context 0 results in a context switch to foreground con- 
text 5 which enters the running state Rf and begins ex- 
ecuting an instruction 70 while background context 3 re- 
mains preempted in state Rb. 

[0051] After executing two instructions to handle its 
activation event, foreground context 5 executes a WAIT 
function during a third instruction cycle 71. This WAIT 
function clears the activity flip-flop f or foreground con- 
text 5, and, atler one more instruction cycle, context 5 
becomes inactive and reverts to the waiting state Wf. 
Since no other foreground contexts are active at this 
time, preempted background context 3 resumes running 
in state Rb and executes the second instruction of its 
time slice 72. On the next instruction cycle, background 
context 3 executes a WAIT function 73. The WAIT func- 
tion 73 clears the activity flip-flop for background context 
3, and after one more instruction cycle, background con- 
text 3 becomes inactive, reverting to the waiting state 
Wb. This allows queued background context 6 to return 
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to the running state Rb at an instruction cycle 74. Note 
that, even though this context switch was not initiated 
by the time slice count decrementing to zero, back- 
ground context 6 enters the running state Rb at the in- 
s struction cycle 74 with a full time slice count value of 
seven, rather than inheriting the partial time slice re- 
maining when the background context 3 executed the 
WAIT function 73. 

[0052] As its second instruction, the background con- 
to text 6 executes an INIT function 76 to the foreground 
context 1 to force the foreground context 1 into a known 
state as may be necessary to recover from a software 
error in the code executed by context 1 . This INIT func- 
tion activates context 1 as a foreground context 
is preempted state Pf with execution set to begin at the 
context 1 initialization vector address in control store. 
Because an active foreground context now exists, back- 
ground context 6 is preempted (at a preemption point 
77) by a context switch to context 1 after execution of 
one more instruction. As its second instruction, context 
1 executes a CLRFG (clear foreground bit) function 78 
which causes context 1 to enter the background queued 
state Qb. Because context 1 is now on the background 
queue and there is already a context in state Rb, context 
1 relinquishes control of the processor (at a relinquish 
point 80) after the instruction cycle following the execu- 
tion of the CLRFG function 78, thereby allowing context 
6 in state Rb to resume executing the remainder of its 
time slice 82. 

[0053] In the remainder of this Detailed Description, 
numeric constants are in decimal unless preceded by 
"Ox" in which case they are in hexadecimal, and bit po- 
sitions are numbered, with bit zero being the least-sig- 
nificant bit. 

[0054] Turning now to FIGURE 3, illustrated are ex- 
emplary per-context control and status registers acces- 
sible to software executing in a processor employing an 
embodiment of the present invention. Nine control bits 
per context 84 have values that are determined by soft- 
ware,and nine status bits per context 86 have values 
that are determined by context controller hardware, but 
whose values may be read or tested in other manners 
by software. The context controller maintains a portion 
of the state of each context. These state bits are not part 
of the execution state (which is saved and restored dur- 
ing context switching) because the context-specific 
state within the context controller is required continu- 
ously for use by activation logic and also as inputs to the 
context switching decision logic. 

[0055] The per-context control bits 84 include a fore- 
ground (FG) bit 88 and an event mask register 90. The 
FG bit 88 is equal to one when the context is in fore- 
ground. The FG bit 88 is illustrated as being set by hard- 
ware reset execution of the INIT function with this con- 
text as the specified target, or execution of the SETFG 
function while this context is running. The FG bit 88 is 
illustrated as being cleared by execution of the CLRFG 
function while this context is running. The event mask 
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register 90 has a bit corresponding to each of the acti- 
vation events associated with the context. 
[0056] In the illustrated embodiment, each context is 
allotted eight activation events; the event mask register 
90 therefore contains eight bits. A given activation event s 
can only activate a context when the corresponding bit 
position number which is equal to the event number has 
a value of one in the context event mask register 90. 
However, as will be explained in greater detail below, 
the assertion of an activation event is recorded in an io 
event flip-flop which remains set until execution of an 
ACKNOWLEDGE (ACK) function for the specified bit. 
Setting of the event flip-flop is unaffected by the contents 
of the event mask register 90. 

[0057] The per-context status bits 86 include an ACT is 
bit 92 and an event status register 94. The ACT bit 92 
is equal to one when the context is active. The ACT bit 
92 is set by either an assertion of a non-masked activa- 
tion event, a setting of the event mask bit for an asserted 
unacknowledged activation event or an execution of the 20 
(NIT function with this context as the specified target. 
The ACT bit 92 is cleared by hardware reset (except for 
context 7, where the ACT bit is set by hardware reset), 
and by execution of the WAIT function while the context 
is running. The event status register 94 has a bit corre- 2s 
sponding to each of the activation events associated 
with the context. These bits are also referred to as event 
flip-flops in some portions of this Detailed Description. 
[0058] As stated above, in the illustrated embodiment, 
each context is allotted eight activation events, dictating 30 
that the event status register 94 contains at least eight 
bits. The bits corresponding to asserted events read are 
equal to one, and the bits corresponding to unasserted 
events read, including acknowledged events, are equal 
to zero. Individual event status register bits (event flip- 35 
flops) are set by context controller hardware upon de- 
tection of assertion (typically a zero-to-one transition) of 
an exogenous or endogenous event signal. The individ- 
ual event status bits may also be set upon execution of 
a SIGNAL function specifying as a destination the sub- 40 
ject event in this context. Individual event status register 
bits are cleared by hardware reset and by executing an 
ACK function with the subject event as the specified tar- 
get, while this context is running. In some cases, a par- 
ticular ACK function may also be generated as a side- 
effect of executing other instructions or accessing par- 
ticular data path (typically I/O port) registers. 
[0059] An implementation example which illustrates 
context definition and usage for an IEEE 802.11 Media 
Access Control (MAC) controller is presented below, so 
The functions of a MAC controller have been divided into 
eight contexts, designated 0 to 7, with 0 being the high- 
est priority. Contexts 0 to 5 are preferably foreground 
and 6 and 7 are preferably background. Each context 
has eight activation events and each of the activation 55 
events generally apply the following defaults: 

A. an event may not be asserted using the SIGNAL 
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function (unless the event is reserved for such pur- 
pose); 

B. an event is cleared using the ACK function; 

C. timer terminal count events occur when the cor- 
responding timer decrements to zero; 

D. timer terminal count events are cleared by writing 
to the corresponding timer's control register with 
ClearTC(bit2) equal to one, not the ACK function; 

F. "assertion" of an external event signal is defined 
as a 0 to 1 transition; 

G. "negation" of an external event signal means a 
1 to 0 transition; and 

H. control bit names are chosen to be meaningful 
when the bit is equal to one. 

[0060] The exemplary contexts and their correspond- 
ing activation events are described below. 
CONTEXT 0 - Debug support (and high-priority, real- 
time events) : 

[0061] Activation Events: 

0) hardware breakpoint (BKPTin); 

1) software breakpoint (signal 0,1); 

2) GP serial shift complete or UART transmitter 
done (GPDN/UTXDN); 

3) interval timer A terminal count (INTATC); 

4) UART receiver done (URXDN); 

5) interval timer B count (INTBTC); 

6) host (computer system) attention (HATN); and 

7) coprocessor attention (CPATN). 

Context 1 - Lower MAC (LMAC) Exception Handling 
[0062] Activation Events: 

0) modem data interface attention (MDIATN); 

1 ) physical layer data not available(IPDA); 

2) IFS (inter-frame space) timer terminal count (IF- 
STC); 

3) inter-context communication from MMAC to 
LMAC; 

4) physical layer transmitter not ready (!TXR); 
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5) beacon/dwelt timer comparator equal (BCNTC); 

6) modem data interface programmable bit bound- 
ary (MDIBIT); and 

5 

7) modem management interface transfer complete 
(MMIDN). 

Context 2 - Lower MAC (LMAC) Data Transfers: 

[0063] Activation Events: 10 

0) modem data interface attention (MDIATN); 

1) interval timer B terminal count (INTBTC); 

75 

2) IFS (inter-frame space) timer terminal count (IF- 
STC); 

3) inter-context communication from MMAC to 
LMAC (signal 2,3); 20 

4) TSFT (the synchronization function timer) wrap- 
around (TSFWRP); 

5) NAV (network allocation vector) timer terminal 2s 
count (INTCTC); 

6) physical layer medium busy (MBUSY); and 

7) physical layer medium not busy (IMBUSY). 30 

Context 3 - Host Interface Support: 
[0064] Activation Events: 

0) buffer access path 0 offset resolution 35 
(BUFATN0); 

1) buffer access path 1 offset resolution 
(BUFATN1); 

40 

2) inter-context communication for status reporting 
to host (signal 3,2); 

3) buffer access path 0 block boundary crossing 
(BLKATN0); 45 

4) buffer access path 1 block boundary crossing 



5) inter-context communication for status reporting so 
to host (signal 3,5); 

6) host interface register attention (HATN); and 

7) inter-context communication from background 55 
(signal 3,7). 

Content 4 - Middle MAC (MMAC) Medium Access and 



Timing: 

[0065] Activation Events: 

0) inter-context communication from LMAC or 
HMAC (signal 4,0); 

1) previously-busy medium becomes available 
(MAVL); 

2) IFS/slot timer terminal count (IFSTC); 

3) interval timer A terminal count (INTATC); 

4) beacon/dwell timer comparator (BCNTC); 

5) modem data interface attention (MDIATN); 

6) software flags 3-0 (shared with context 7, event 

7) ; and 

7) modem management interface transfer complete 
(MMfDI). 

Context 5 - WEP (wired equivalent privacy) Decryption 
Support: 

[0066] Activation Events: 

0) inter-context communication for status reporting 
(signal 5,0); 

1 ) decryption keystream values ready (DECRYPT); 

2) GP serial shift complete or UART transmitter 
done (GPDN/UTXDN); 

3) inter-context communication (signal 5,3); 

4) UART receiver transfer done (URXDN); 

5) inter-context communication (signal 5,5); 

6) interval timer D terminal count (INTDTC); and 

7) modem management interface transfer complete 
(MMIDN). 

Context 6 - Additional Access Point Functions: 
[0067] Aciivaiion Events: 

0) software flags 11-8; 

1) software flags 15-12; 

2) GP serial shift complete or UART transmitter 
done (GPDN/UTXDN); 

3) interval timer A terminal count (INTATC); 
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4) software flags 7-4; 

5) interval timer B terminal count (INTBTC); 

6) interval timer D terminal count (INTDTC); and 

7) coprocessor attention (CPATN). 

Context 7 - Upper MAC (UMAC) and Miscellaneous 
Support: 

[0068] Activation Events: 

0) software flags 19-16; 

1) software flags 23-20; 

2) software flags 27-24; 

3) interval timer A terminal count (INTATC); 

4) beacon/dwell timer comparator (BCNTC); 

5) interval timer B terminal count (INTBTC); 

6) interval timer D terminal count (INTDTC); and 

7) software flags 3-0 (shared with context 4, event 
6)- 

[0069] Turning now to FIGURE 4, illustrated is a sys- 
tem diagram of a typical processor or I/O controller in- 
corporating an embodiment of the context controller of 
the present invention. This diagram (as well as those 
illustrated in FIGURES 5, 6 and 7) is presented using 
the well-known graphical syntax of the Specification and 
Description Language (SDL) as standardized by the In- 
ternational Telecommunication Union in ITU-T Recom- 
mendation Z.100 (03/93). 

[0070] The system behavior is presented using this 
formal description language because more precision 
and broader general applicability are achievable. For 
example, a schematic fragment could be used to high- 
light implementation characteristics of the illustrated 
embodiment. However, since this context controller is 
applicable to almost any type of processor, the schemat- 
ic for a particular processor is likely to omit aspects of 
the control sequences which are implicit for that proc- 
essor but may be relevant to another processor using a 
different architecture. Also, a conventional state dia- 
gram is a more informal notation having a similar objec- 
tive to the SDL process diagram. SDL has a rigorously 
defined graphical syntax, however, achieving much less 
ambiguity. Indeed, it has been found that many "bound- 
ary conditions 1 ' in the behavior of this controller are not 
adequately explained by conventional state diagrams. 
Examples of these boundary conditions, all of which are 
covered by the SDL description herein, include: (1) 
What happens if a context is preempted between exe- 



cution of a WAIT function and execution of the instruc- 
tion following the WAIT function? (2) What happens if a 
context executes the ACK function for the event which 
caused its activation during the instruction after execut- 

s ing a WAIT function? and (3) If a background context's 
time slice ends on the same instruction cycle as it exe- 
cutes a SETFG function, does that context continue run- 
ning in foreground, or does the next context in state Qb 
execute one instruction before being preempted by the 

10 new foreground context? Also, SDL is able to describe 
the behavior of the context controller with more preci- 
sion and less ambiguity than is possible using English 
prose. Therefore, the SDL descriptions presented in the 
following paragraphs are intended to serve as both a 

'5 general and a detailed guide to the structure and intend- 
ed purpose of the significant features of several embod- 
iments of this invention. 

[0071] An SDL system diagram 100 shows the rele- 
vant top-level functional blocks of the processor used in 

20 the illustrated embodiment. Text symbols 102 and 104 
contain the definitions of the system -specific extensions 
to SDL's predefined data types, declarations of the re- 
mote variables used for implicit inter-block communica- 
tion via the export/import mechanism and declarations 

2S of the names and parameter types of the signals used 
for explicit inter-block communication. The system dia- 
gram 100 shown comprises five functional blocks: a 
clock generator 1 06, a sequencer 1 08, an instruction de- 
coder 1 1 2, a data path and interface resources manager 

30 114 and a context controller 1 1 0. 

[0072] The clock generator 106 accepts an input 
clock, or timebase reference (e.g., crystal-controlled 
signal) from which is generated a clock, via Clocks In 
channel 122 and a hardware reset signal via Resetln 

35 channel 120. The clock generator 106 generates the cy- 
cle clocks used by all other blocks. These cycle clocks 
subdivide the instruction cycle into four, substantially 
equal portions. This is done using a pair of square waves 
in quadrature, resulting in four clock edges at which to 

40 initiate various actions. Actual clock waveforms are il- 
lustrated in FIGURES 8 and 9, with a master clock 
MCLK signal 504 delimiting the instruction cycle bound- 
aries and a quadrature clock QCLK signal 506 providing 
additional clock edges within each instruction cycle. The 

45 tour edges, in sequential order, are: a rising edge of the 
MCLK signal 504, designated Mr 517, which marks the 
end of one instruction cycle and the beginning of the 
next instruction cycle, a rising edge of the QCLK signal 
506, designated Qr 518, which occurs 25% of the way 

50 through each instruction cycle : a falling edge of the 
MCLK signal 504, designated Mf 51 9, which occurs 50% 
of the way through each instruction cycle, and a falling 
edge of the QCLK signal 506, designated Qf 520, which 
occurs 75% of the way through each instruction cycle. 

55 [0073] In the SDL model, the clock generator 106 
sends appropriate Mr 517, Qr 518, Mf 519 or Qf 520 
signals, as well as a reset signal, to all other functional 
blocks. The clock generator 106 operates while the 
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processor is either running or idle, but can shut down 
most of its circuitry, including the generation of the 
MCLK signal 504 and the QCLK signal 506, during a 
very-low-power sleep mode, which is entered when the 
clock generator 106 receives a sleep signal from the 
context controller 110 via channel ClkCctl 140. 
[0074] In many implementations, it is not possible to 
execute an instruction during every clock cycle. As a re- 
sult, the instruction decoder 112, sequencer 108 and 
context controller 1 1 0 only perform theirf unctions during 
the cycle when the instruction is actually being execut- 
ed, as identified by the remote Boolean variable a ien B 
being true (see text symbols 102). 
[0075] The sequencer 108 generates instruction ad- 
dresses and initiates instruction fetch cycles via a ToCS 
channel 116. These addresses connect to a control 
store array 117 logically external to the processor 100. 
Note that, depending on the implementation technology 
and desired performance level, the control store array 
1 1 7 and an associated data store 1 27 may be physically 
separate, fully co-located in a single memory device, or 
any hybrid thereof. The sequencer 108 receives context 
switching signals CsLoad (to retrieve saved context 
state information), CsStore (to save context state infor- 
mation) and InitSeq (to set a context execution address 
to the appropriate initialization vector) from the context 
controller 110 via CctlSeq channel 141. 
[0076] The instruction decoder 112 receives the in- 
struction words fetched under control of the sequencer 
108 via a FromCS channel 118. Decoded instructions 
are sent as signals, with the instruction field values as 
parameters, to all other blocks as appropriate. The in- 
structions requiring processing in the context controller 
110 are sent via an InstCctl channel 142. 
[0077] The data path and interface resources manag- 
er 114 represents the remainder of the processor, in- 
cluding the ALU, programmer-visible registers and so 
forth. All of the I/O device, host computer (if any) and 
local data memory interfaces (channelsl26, 128, 130, 
1 32) connect to this functional block. The data path and 
interface resources manager 114 sends event signals 
to the context controller 110 and receives an AckEv sig- 
nal (which indicates that software has executed an ACK 
function to acknowledge a specific prior Event), CsLoad 
and CsStore signals (to restore and to save context 
state information), and SetCy and ClearCy signals (to 
set and clear a carry flag for use after hardware reset 
and !N!T functions) from the contexi Cuiuroiiui 110 via 
a CctllDP channel 143. This functional block also ex- 
ports the values of ien (equal to true if the current clock 
cycle is an instruction execution cycle) and slice (the last 
value specified by software for the initial instruction 
count for each background time slice). 
[0078] The context controller 1 1 0 advantageously ac- 
cepts exogenous event signals via an Eventsln channel 
124, and communicates with other functional blocks as 
mentioned above. This functional block also exports the 
values of Boolean variables asleep (equal to true when 



in sleep mode) CSW (equal to true during the second 
half of context switch cycles) and idle (equal to true 
when there are no active contexts), CtxNum (context 
number), variables context (the running context's 

s number), and nctx (the number of the context to which 
execution is being switched). And, this functional block 
also exports BitString variables events (the current con- 
text's event status register) and mask (the current con- 
text's event mask register value). 

w [0079] Turning now to FIGURE 5, illustrated is an SDL 
process interaction diagram showing an internal struc- 
ture of the context controller 110 illustrated in FIGURE 
4. The internal structures of the other top-level blocks 
are not presented herein because they are not part of 

is the present invention and are not required to understand 
the behavior of the context controller 110. 
[0080] Two processes are illustrated as being con- 
tained in the context controller block 110. An event syn- 
chronizer 1 50 accepts exogenous event signals from an 

20 AsyncEvents signal route 158 and synchronizes them 
with the master clock rising edge Mr 517, which is pro- 
vided by the clock generator 106 via a ClkSyn signal 
route 156. These events are sent on, via a SyncEvents 
signal route 166, as event signals, just as with the (in- 

2S herently synchronized) event signals from endogenous 
sources on a PriDP signal route 164. 
[0081] The fundamental context control state ma- 
chine operates in an event prioritizer process 1 52 in this 
embodiment. The event prioritizer 152 receives input 

30 signals from the clock generator 106 via a ClkPri signal 
route 154, event signals from the event synchronizer 
150 via a SyncEvents signal route 166 and data path 
CctlDP functions 143 via a PriDP signal route 164. Ad- 
ditionally, decode signals for various instructions rele- 
ts vant to context control and inter-context communication 
from an instruction decoder over the InstCctl channel 
142 via an InstPri signal route 162 are received. 
[0082] Turning now to FIGURE 6 : illustrated is a proc- 
ess diagram of the event synchronization process illus- 

40 trated in FIGURE 5 which depicts the operation of the 
event synchronizer 1 50. This process ensures that each 
incoming ExtEvent signal 208 is saved until the occur- 
rence of a master clock rising edge Mr 206, at which 
time all saved ExtEvent signals 214 are received and 

45 immediately passed to th e event prioritizer 1 52 as Event 
signals 218. 

[0083] Turning now to FIGURES 7A, 7B, 7C and 7D, 
coiieciiveiy iiiustrated are process diagrams ot the event 
prioritization process shown in FIGURE 5 defining the 
50 state transitions of the event prioritizer 152 process. 
This process implements the event driven and time- 
sliced context switching functions for this embodiment 
of the present invention. 

[0084] FIGURE 7A defines the startup and reset se- 
55 quences. In "all states a symbol 272, a reset signal 274 
takes precedence over all other input signals and caus- 
es the process input queue (symbols 276-280) to be 
flushed before joining a startup initialization (symbol 
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282) starting at a start symbol 254. A sequence (sym- 
bols 256-270) initializes all relevant variables, clearing 
event masks, event status registers and wait flip-flops, 
setting all contexts to foreground, and clearing ail ACT 
flip-flops, except for that of context 7, which is forced s 
active. 

[0085] FIGURE 7B defines operation during the sec- 
ond half of each cycle, an Mf to Mr period, (a period from 
a master clock falling edge Mf to its next rising edge Mr), 
as well as the events immediately following the receipt 
of a master clock rising edge Mr 292. Running and idle 
states 284 both have the same transitions, since an in- 
struction is executed during the cycle following a WAIT 
function, and because events may occur and need to 
be processed during any cycle, including times when the 
processor is idle. During the Mf-to-Mr period, all instruc- 
tion decode signals except an ACK (Acklnst), a WAIT 
or a SLEEP function 300 are processed immediately. 
These three signals are saved for processing after the 
master clock rising edge Mr 292 because they must be 
handled after all Event signals 288 have been proc- 
essed. The instructions handled ahead of the master 
clock rising edge Mr 292 (that is, the signals 286, 290, 
294, 296, 209) may alter information that has to be 
saved at the master clock rising edge Mr 292 if a context 
switch occurs. 

[0086] After the master clock rising edge Mr 292, on 
cycles when ien is equal to true (one) (293), CSW (con- 
text switch in progress flag), CTX (current context 
number), NCTX ((next context number) and the event 
mask and event status registers are updated (symbols 
320, 321). The processor may enter a Sleeping state 
(symbol 338) during which the processor clocks stop, 
and only a low-frequency sleep timer operates until ei- 
ther a Sleeping timeout (a Wake signal, in symbol 340) 
or a hardware reset occurs. If not asleep, a time slice 
instruction count is decremented (symbol 330) if a back- 
ground context is running (symbols 326, 328). If the slice 
count decrements to zero (symbol 332), a time slice con- 
text switch is initiated by advancing the round-robin cur- 
Bg (current background context) pointer by one, modulo 
the number of contexts (symbol 334), and the time slice 
instruction count is reset (symbol 335) to its pro- 
grammed value. Then a prioritize state 336 is entered 
to handle an Mr-to Qr period (a period from a master 
clock rising edge Mr to the next quadrature clock rising 
edge Qr). 

[0087] FIGURE 7C defines operation during the first 
quarter of each cycle (the Mr-to Qr period). This is the 
time when the events sampled at the master clock rising 
edge Mr 292 are masked and the ACT flip-flops are up- 
dated in preparation for making a context switching de- 
cision after a quadrature clock rising edge Qr 380. An 
ACK (Acklnst) signal 352, a WAIT signal 360 and a 
SLEEP signal 366 are handled prior to the quadrature 
clock rising edge Qr 380, and a masking and ACT up- 
dating sequence (symbols 386-392) occurs following 
the quadrature clock rising edge Qr 380. 



[0088] The updating of ACT bits is depicted as an it- 
erative process (symbols 388-392) for clarity regarding 
the operation being performed. This operation is typical- 
ly performed for all contexts in parallel. A subtle, but very 
important action in FIGURE 7C is the handling of a WAIT 
function 360, where the occurrence of the WAIT function 
360 is recorded at the index of the previous (prev) con- 
text (symbol 362) (which is the context that was running 
prior to the master clock rising edge Mr 292 when the 
WAIT function 360was decoded). Then the clearing of 
the ACT flip-flop (symbols 382-384) is done at the index 
of the current (ctx) context. The values of prev and ctx 
will be equal both before and after the quadrature clock 
rising edge Qr 380 in all cases except when a context 
switch occurred immediately preceding the master clock 
rising edge Mr 292. This means that a context executing 
a WAIT function on the last cycle before a context switch 
remains active, but with its Wait flip-flop (bit in the waited 
bit string) being equal to one until that context is again 
able to run and execute the instruction following the 
WAIT function. Another interesting action in FIGURE 7C 
is the sending of an AckEv signal 356 to the Data Path 
when an ACK function 352 is processed. This is done 
to permit side-effects in the device or host interface logic 
to be performed when a specific event is acknowledged. 
[0089] FIGURE 7D defines operation during the sec- 
ond quarter of each cycle, a Qr-to Mf period, (a period 
from a quadrature clock rising edge Qrtothe next mas- 
ter clock falling edge Mf). This is the time period when 
events are prioritized and the context switching deci- 
sions are made. The first set of actions (symbols 
422-428) searches for a possible preemption. The 
search is depicted as an iterative process for clarity re- 
garding the operation being performed. This operation 
is typically performed for all contexts in parallel. If the 
running context is in foreground, the search is over the 
range 0:ctx, whereas if the running context is in back- 
ground the search is over the range 0:7 because all fore- 
ground contexts have priority over any background con- 
text (symbol 423). The priority encoding (symbol 424) is 
implicit in the ascending context number 424 (descend- 
ing priority) sequence. If an active, foreground context 
is found, its number is recorded in nctx (symbol452). 
Otherwise, a search (symbols 430-434) is conducted for 
an active background context starting at the indicated 
current background context and continuing to higher 
context numbers (modulo 8). 

[0090] If a time slice (the symbol 334 of FIGURE 7B) 
ends at the master clock rising edge Mr 292 of this cycle, 
the indicated curBg will already have been incremented, 
meaning the search will start from the context after the 
one that is currently running and will only re-select the 
same context if no other contexts are in the queued state 
Qb. In the case of a preempted context in the back- 
ground running state Rb that can now be resumed, this 
test (symbol430) will exit immediately to a set new con- 
text number (nctx) 450. If either a foreground (set new 
context number (nctx) 452) or a background (symbol 
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450) search finds a context to run, the new context 
number (nctx) is compared with the current context 
number (ctx) (symbol 454) to determine whether a con- 
text switch is needed. If a context switch is not needed, 
no further context control activities occur during this cy- 
cle and the controller returns to a running state 458. 
[0091] If a context switch is required, the controller en- 
ters Start -CSW state 456 saving the input signals 462 
until a master clock falling edge Mf occurs (symbol 460). 
Then CSW is asserted (symbols 474-476) is asserted, 
and the loading of the saved state of the next context 
(symbol 478) is initiated while saving the current context 
state (symbol 480) is requested. The reason loading is 
requested before storing is explained below more fully 
in conjunction with FIGURES 8 and 9. 
[0092] If there are no active contexts, the controller 
saves all input signals (symbol 440) until the master 
clock falling edge Mf occurs (symbol 438), then indi- 
cates an Idle state 442 and requests saving the current 
context state 446 before actually entering an Idle state 
448. The context state is saved because there is no 
guarantee that the same context will be the first context 
to run at the end of the idle period. In effect, the transition 
to and from the Idle state 448 is a split context switch, 
with saving during the transition to idle (symbols 
442-446), and loading during the transition from idle 
(symbols 466-470). During the idle state, the clocks con- 
tinue to run and events continue to be sampled, but in- 
structions are neither fetched nor executed. 
[0093] If the processor is implemented using comple- 
mentary metal oxide semiconductor (CMOS), or anoth- 
er process technology where power consumption is very 
tow or essentially zero when the circuit elements are not 
being clocked or changing level, the Idle state 448 pro- 
vides an inherent power saving mode for most of the 
processor, including sequencer, instruction decoderand 
data path. If a still lower power operating mode is de- 
sired, the SLEEP function 366 (in FIGURE 7C) can stop 
the high-speed clocks, along with suspending event 
monitoring, leaving only a low-frequency sleep timer in 
operation. 

[0094] Turning now to FIGURE 8, illustrated is a tim- 
ing diagram for a context switch controlled by the 
present invention in which a current context's state is 
stored into, and the next context's state is loaded from, 
synchronous (self-timed) SRAM or register files. The 
timing diagrams depicted (in both FIGURES 8 and 9) 
identify the differences inquired Io use each of two dif- 
ferent types of memory technology for storing the exe- 
cution states of non-running contexts. Each of these tim- 
ing sequences has the beneficial advantage that the 
context switch operation does not require extra cycles 
to save and restore the context execution state, but rath- 
er performs this function in parallel with execution of the 
last instruction of the context being switched. To employ 
this technique, a processor data path should include 
dedicated register files or static RAM (SRAM) arrays for 
each register in the execution state. The illustrated em- 



bodiment of the invention may be used in conjunction 
with processor data paths that do not provide such stor- 
age. However, more overhead is associated with con- 
text switching on such processors, due to possible extra 

5 cycles and an execution of additional instructions to 
save and restore context execution states. 
[0095] The simpler timing and control signal sequenc- 
ing, shown in FIGURE 8, is achieved when the save ar- 
rays are implemented using synchronous static (self- 

10 timed) RAM (SRAM). This is also the timing that results 
from a direct implementation based on the SDL process 
defined in FIGURE 7. Although programmer-visible be- 
havior is identical, greater complexity is required to use 
asynchronous static RAM for the save arrays (as will be 

is discussed in conjunction with FIGURE 9). An approach 
using synchronous SRAM permits shorter cycle times 
and lower power consumption due to a reduced number 
of signal transitions and an elimination of control signal 
duty cycles shorter than 50% of the instruction cycle 

20 time, assuming identical performance ol the synchro- 
nous SRAM and asynchronous SRAM devices. 
[0096] The synchronous SRAM captures the write ad- 
dress and data at a leading edge of each write enable 
pulse, and completes the write operation using internally 

2s generated control signals, without need for stable input 
signals (other than power) during the remainder of the 
write cycle. Cell-based, semi-custom integrated circuits 
employing synchronous SFIAM that use register file 
cells with both a read port and a write port having inde- 

30 pendent addresses are readily available. The control 
signal timing for a context switch becomes relatively 
simple when using these synchronous SRAM cells to 
implement the save arrays, as shown in FIGURE 8. 
[0097] During each instruction execute cycle 500, 502 

35 a context controller 514 samples activation event sig- 
nals at a master clock rising edge Mr 517 allowing the 
first quarter of the cycle for settling and gating of the 
synchronized signals (time interval 532). At a quadra- 
ture clock rising edge Qr 518, all ACT flip-flops are up- 

40 dated and the priority encoding and comparison opera- 
tions determine the need for a context switch, selecting 
a next context if required (time interval 533). In parallel 
with these context controller activities, a processor (time 
interval 516) has been executing an instruction initiated 

45 at the master clock rising edge Mr 517, without regard 
for whether a context switch may be necessary during 
this instruction execution cycle. If a processor data path 
has combinatorial paths from internal register sources 
that are expected to be stable throughout the execution 

50 cycle, values on these paths must be latched at a master 
clock falling edge Mf 51 9 to permit readout of a saved 
state of a next context to begin (time interval 540). Al- 
ternately, if a processor designer prefers to add over- 
head cycles for reading a saved context state, this latch- 

55 jng is not required. But, in most cases, one or more cy- 
cles are inserted and a net effect will be a slowdown of 
processing and real-time response if these latches are 
eliminated, resulting in a period when instructions can- 
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not be executed between a last instruction cycle of an 
old context and a first instruction cycle of a new context. 
[0098] At the master clock failing edge Mf 519, the 
context controller can determine whether a context 
switch is required (time interval 534), and assert an 
CSW signal 522 if so. The target state to be restored is 
indicated by placing a context number of a next context 
on a NCTX[2:0] signal group 530. This starts a "saved 
State" readout'of a next context (time interval 540) using 
a NCTX[2:0] signal group 512 to address the save ar- 
rays in parallel with a completion of the last instruction 
of the current context (whose context number remains 
on a CTX[2:0] signal group 524). 
[0099] At the end of this context switch cycle desig- 
nated by the master clock rising edge Mr 517 (separat- 
ing cycle 500 from cycle 502), an. execution state of a 
current context, including an outcome generated during 
this execution cycle 500, is stored (time interval 542) 
using a CTX [2:0] signal group 510 to address the save 
arrays. The save array write operation (time interval 
542) is initiated by the master clock rising edge Mr 517 
when a CSW signal 508 is asserted (time interval 522). 
Due to the advantageous characteristics of writing to 
synchronous SRAM, a first instruction of the next con- 
text can commence execution immediately (time inter- 
val 536), since neither the address nor data being writ- 
ten to the save array has to be held after the master 
clock rising edge Mr 517 occurs, which ends cycle 500. 
For proper execution, the synchronous SRAM cycle 
time, including write recovery, may not exceed 50% of 
an instruction cycle period. The same master clock ris- 
ing edge Mr 517 transition that initiates an SRAM write 
may also be advantageously employed to complete a 
context switch with a CSW signal 508 negated and a 
CTX [2:0] signal group 510 updated to a new context 
number 526. 

[0100] Turning now to FIGURE 9, illustrated is a tim- 
ing diagram for a context switch controlled by the 
present invention in which the current context's state is 
stored into, and the next context's state is loaded from, 
asynchronous SRAM or register files. Conventional, or 
asynchronous, SRAM requires that a write address and 
data be stable throughout a relevant portion of a write 
cycle. This necessitates a setup time prior to a trailing 
edge of a write enable pulse and sometimes requires a 
short hold time following this trailing edge. Many semi- 
custom integrated circuit technologies can supply RAM 
arrays or register files using asynchronous SRAM that 
provides a single address and data port which may be 
used for either reading or writing. Separate SRAM and 
register file chips that operate in this manner are also 
widely available. 

[0101] To use this type of conventional, single-port 
SRAM to implement the save arrays, control signal tim- 
ing for a context switch becomes somewhat more com- 
plicated, as shown in FIGURE 9. General timing is the 
same as in FIGURE 8, and similar elements are identi- 
fied using the same reference numbers. A primary dif- 



ference is the generation of the NCTX[2:0] signal group 
51 2, in operations by a context controller 51 4 ; and a data 
path 516 during and immediately after an assertion of a 
CSW signal 548 (as detailed in times 522, 528, 530, 534, 
s 535, 537, 540, 541, 543 of FIGURE 9). It is necessary 
to use asynchronous SRAM with a cycle time that does 
not exceed 25% of the instruction cycle period including 
write recovery in order to avoid insertion of overhead 
cycles, assuming no instructions are executed while 
saving and restoring a context state. This speed require- 
ment is twice as fast as that needed to achieve the same 
processor cycle rate when using synchronous SRAM. 
The context switch activities are identical during the first 
half of the context switch cycle (time intervals 532, 533, 
538). At a master clock falling edge Mf 51 9 of the context 
switch cycle, a CSW signal 508 is asserted (time interval 
522) and a NCTX[2:0] signal group 51 2 is set to the next 
context number (time interval 534). Address and data 
information must be stable while writing the results of 
the last instruction executed by the current context into 
the save arrays. Therefore, only a period from the mas- 
ter clock falling edge Mf 51 9 to the next quadrature clock 
falling edge Qf 520 is available for readout of the saved 
state for the next context (time interval 540). This out- 
come is then preferably latched and held during a period 
from the quadrature clock falling edge Qf 520 to the next 
master clock rising edge Mr 517. Then, these latched 
values are advantageously transferred to the proces- 
sor's working registers (time interval 543). At the quad- 
rature clock falling edge Qf 520, the value of the NCTX 
[2:0] signal group 51 2 switches back to the current con- 
text number (time interval 535), allowing the current con- 
text state including results of this instruction (cycle 500) 
to be written to the save arrays (time interval 541). At 
the master clock rising edge Mr 51 7, the NCTX[2:0] sig- 
nal group 51 2 switches back to the next context number 
(time interval 530) and execution of a first instruction of 
the next context begins (time interval 537). 
[0102] Unlike the synchronous SRAM implementa- 
tion, the write operation is completed at the master clock 
rising edge Mr 51 7. Use of the asynchronous SRAM re- 
quires that the data path results be stable relatively early 
to allow writing to the save arrays during the interval 
from the quadrature clock falling edge Qf 520 to the 
master clock rising edge Mr 51 7. Whereas with synchro- 
nous SRAM, the data path results are not needed until 
just prior to the master clock rising edge Mr 517, which 
facilitates shorter instruction cycles and therefore faster 
processing. 

[0103] Turning now to FIGURE 10, illustrated is a 
schematic diagram of one embodiment of a circuit suit- 
able for implementing event recording, event masking 
and event acknowledgment for each activation event, 
as well as management of a context activity bit, including 
initialization request and wait request logic where the 
details of event recording, masking and acknowledg- 
ment within the context controller may better be under- 
stood. In one embodiment of the present invention, the 
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event recorder is embodied in at least one flip-flop within 
the context controller. Of course, the event recorder can 
be located in a register or other memory location. 
[0104] A generalized schematic fragment of a "slice 0 
of a context controller event logic is presented for a sin- s 
gle event including an ACT bit and WAIT function logic 
of the context associated with that event. In this dia- 
gram, all logic signals are considered to be asserted in 
the "high" true (logical one) state. This schematic frag- 
ment is illustrative of an embodiment of the event logic 
and is not meant to be a limitation on practice of the 
present invention. 

[01 05] An exogenous event signal 550 may be asse rt- 
ed with either polarity, so a programmable inversion 
function 560, under control of a software signal 551 may 
be provided to establish a high-true signal for internal 
use. Because this exogenous signal has an undeter- 
mined phase relationship with the internal clocks, a syn- 
chronizer 562 that synchronizes the input signal with a 
master clock rising edge Mr 517 prior to its internal use 
is employed. A plurality of sources may be used to set 
an event flip-flop 570 including a leading edge of a syn- 
chronized external signal 564, a leading edge of an in- 
ternal source 566, or a software SIGNAL function 552 
which designates this context and event. These event 
sources are combined by an OR gate 568 whose output 
enables an event flip-flop 570 to be set at the master 
clock rising edge Mr 517. 

[01 06] Because the event flip-flop D-input 570 is hard- 
wired true (to a logical one as shown), negation of an 
event signal after setting the event flip-flop 570 does not 
rescind the event. The event flip-flop output 570 may be 
read by software as a bit in the event status register 94 
and as a testable condition in an events condition signal 
group 596 if the processor provides instructions such as 
the SKPn of the illustrated embodiment (as described 
below). The event flip-flop 570 can be cleared either by 
a hardware reset 555 or an AND gate 572 output, whose 
ANDed inputs incorporate the execution of an ACK (ac- 
knowledge) function 554 for this event number while this 
context is running (a signal 556), applied through an OR 
gate 574. 

[0107] An appropriate bit for this context event from 
the context's event mask register 94 : event mask bit 558 
is ANDed in an AND gate 580 with an event flip-flop out- 
put 570 and applied to the input of an ACT flip-flop 590 
through an OR gate 584. The output of this AND gate 
580 is also used when performing priority encoding of 
the context events for the VECTOR function, as is de- 
scribed in greater detail below. A masked event signal 
from the AND gate 580 is ORed in the OR gate 584 with 
the masked event signals from all other events associ- 
ated with this context including a signal from the output 
gate of the wait logic through an AND gate 582. 
[01 08] A logical true output condition of the OR gate 
584 enables the ACT flip-flop 590, allowing the ACTflip- 
flop 590 to be set to the output value of a NOT inverter 
586 at the quadrature clock rising edge Qr 51 8. By using 



the output of the AND gate 582 and an inversion of the 
same signal through the NOT inverter 586, the Act flip- 
flop 590 D-input may be enabled. The ACT flip-flop 590 
is set at the quadrature clock rising edge Qr 518 if one 
or more activation events are asserted, and no WAIT 
function was executed during the preceding instruction 
cycle. The ACT flip-flop 590 may also be set directly by 
execution of an I NIT function 588 to this context, and 
cleared directly by a hardware reset signal 555. The 
ACT flip-flop output 590 is also used by the context pri- 
ority logic and is inverted by a NOT inverter 592 to clear 
a WAIT flip-flop 578. The ACT flip-flop 590 is cleared 
through the NOT inverter 586 if a WAIT function was 
executed during the preceding instruction cycle whether 
or not any activation events are asserted. 
[0109] The WAIT flip-flop 578 is needed because a 
context may be preempted between executing a WAIT 
function and executing an instruction which follows the 
WAIT function. (An example of this occurrence is shown 
at 53, 54 and 58 of FIGURE 2). When a WAIT function 
557 is decoded by an AND gate 576 while this context 
is running (a signal 556), the WAIT ftip-flop 578 is ena- 
bled to set at the master clock rising edge Mr 517. Be- 
cause a context must be active to execute a WAIT func- 
tion, this action records the occurrence of the WAIT 
function since the output of the ACT flip-flop 590 being 
in the true state negates the clear input of the WAIT flip- 
flop 578 through the NOT inverter 592. 
[0110] At the next quadrature clock rising edge Qr 
518, in which this context is a running state (the signal 
556), the ACT flip-flop 590 is cleared due to assertion 
of the AND gate output 582. If this context is preempted 
or time-sliced at the same instruction cycle boundary 
(the master clock rising edge Mr 51 7) that the WAIT flip- 
flop 578 is set, the context will not be running. Hence, 
the context running signal 556 will be negated prior to 
the next quadrature rising edge Qr 518, and the ACT 
flip-flop 590 will remain set. When this context resumes 
running, the ACT flip-flop 590 will be cleared at the quad- 
rature clock rising edge Qr 518 of the first instruction 
cycle causing the context to become inactive after exe- 
cuting this one instruction. The negation of the ACT flip- 
flop output 590 clears the WAIT flip-flop 578 via the NOT 
inverter 592. 

[0111] Turning now to FIGURE 11, illustrated are field 
and bit assignments of machine instructions pertaining 
to context control and inter-context communication in 
the instruction set according to one embodiment of the 
present invention. The details of the instruction decod- 
ing and field encoding are not directly relevant to the 
present invention, and this figure is included primarily to 
illustrate the operand fields that provide information 
needed by the context controller. 

[0112] Testing of bits in the context event status reg- 
ister 94 is most efficiently accomplished using SKPx in- 
structions 600. These instructions perform a test under 
mask or bitwise comparison between a specified 'con- 
dition group" (C-group) 604 of eight related signals and 
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an eight-bit mask value 605 contained in the instruction 
word. If the condition specified by a test operation 603 
is true, the instruction following the SKPx is skipped. 
Relevant to the present invention is C-group 01 : an 
"EVENTS" group 608 which is unaffected by the event s 
mask and which tests the contents of the event status 
register 94 of the running context. 
[01 13] A VECTOR instruction 61 0 is decoded from the 
same opcode 602 as the SKPx instructions but has a 
distinctive value in its "test operation" field 61 2. The oth- 10 
er 10 bits of the VECTOR instruction word are a vector 
base address 613 whose use is described below. 
[0114] A SIGNAL instruction 620 is used to implement 
an inter-context software signaling function previously 
described. The SIGNAL instruction 620 is one of the 15 
processor control instructions based on the value of an 
extended opcode field 622 with a distinctive subdecode 
value 623. Two parameter fields are decoded within the 
context controller when a SIGNAL instruction is execut- 
ed. A specified event number 624 identifies a particular 20 
event to assert among the events associated with a 
specified context number 625. All events may be the tar- 
get of the SIGNAL instruction 620, but implementation 
details in particular instances of this context controller 
and connected event sources may make it difficult to al- 25 
low the SIGNAL instruction 620 to assert certain condi- 
tions. 

[01 1 S] An ACK instruction 630 and an I NIT instruction 
640 are formatted and decoded in a similar way to the 
SIGNAL instruction620 but have only one parameter 30 
field each. The ACK instruction 630 carries only an 
event number 624, because acknowledgment of a con- 
text's events is only permitted by code executing in the 
same context, so a context number parameter would be 
superfluous. An INIT instruction 640 carries only a con- 35 
text number 625 because the initialize function is direct- 
ed to a context, not to an event associated with a con- 
text. 

[0116] A STROBE instruction 650 can generate a 
specified one out of as many as 32 discrete, imperative 40 
control functions 653. A WAIT instruction 654, is of rel- 
evance to the context controller, which clears the ACT 
bit of the running context; a SETFG instruction655, 
which sets the FG bit of the running context; a CLRFG 
instruction 656, which clears the FG bit of the running 45 
context; and a SLEEP instruction 657, which causes the 
context controller to suspend operation and to allow the 
processor to enter an extremely low-power sleep mode. 
[0117] The INIT instruction 640 is used to force the 
target context into a known state either for initialization so 
or for error recovery. Execution of the INIT instruction 
640 sets both the ACT and FG bits to be logically true 
in the context specified in the instruction. It also sets a 
context CY (carry) flag to allow contexts to distinguish 
between hardware reset (when CY is equal to zero) and 55 
INIT (when CY is equal to one) and forces the context 
to begin executing at a context -specific initialization vec- 
tor. 



[0118] Turning now to FIGURE 12, illustrated are 
sources of bits used to generate control store addresses 
on the processor according to one embodiment of the 
invention. The initialization vector address for a context- 
specific initialization vector mentioned above, may be 
formed by placing the contents of a context number field 
625 of the INIT instruction 640 (of FIGURE 11) into bit 
locations five through three of an address word contain- 
ing all zeros as seen in an entry for an INIT Instruction 
666 shown in FIGURE 12. 

[0119] Turning now to FIGURE 13, illustrated is an ex- 
emplary data structure diagram for initialization vectors 
in control store according to one embodiment of the 
present invention. As shown, this embodiment uses a 
set of eight initialization vectors 670-677 located at suc- 
cessive four-word intervals, control store address pat- 
tern 678 starting at control store address 0x0000. A four- 
word vector pitch was chosen because a long, absolute 
branch on this processor requires three words : and all 
but the last (context 7) vector 677 are likely to require 
such a branch. Requiring no branch for context 7 is use- 
ful because context 7 is the sole context to be active 
after hardware reset. 

[0120] Therefore, the code at the context 7 initializa- 
tion vector is used to initialize the other contexts after 
hardware reset and for handling an I NIT function to con- 
text 7. The vector pitch for use on other processors can 
be chosen in an embodiment-dependent manner. It is 
also desirable on some processors to use the contents 
of the initialization vector as an address which performs 
an indirect branch through the vector, rather than start- 
ing program execution at the vector address. The VEC- 
TOR instruction 610, shown in FIGURE 11, is useful for 
priority-based decoding of the event(s) causing context 
activation. 

[0121] In one embodiment of the present invention, 
the event-dependent vector is selected from the group 
consisting of a direct branch and an indirect branch. 
Those skilled in the art are familiar with various well- 
known addressing schemes, all of which being within 
the broad scope of the present invention. 
[0122] Turning now to FIGURE 14, illustrated is a di- 
agram setting forth target address generation by vector 
instruction used to prioritize and decode specific context 
activation bits on the processor according to one em- 
bodiment of the present invention. As stated earlier, the 
VECTOR instruction 610 is useful for priority-based de- 
coding of the event(s) causing context activation. When 
executed, this instruction branches to one of a set of 
eight handlers 680-687 in a vector table 690 located in 
control store. 

[01 23] A vector table base address 61 3 is specified in 
the ten lowest-order bits of the VECTOR instruction 
word 61 0. A specific vector is selected by priority encod- 
ing the context event status register 94 ANDed with the 
context event mask register 90. Then, using a resulting 
event number 694 as bit positions six through four along 
with a set of zeros 692 in bit positions three through zero 
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of the vector address 678 (as seen in FIGURE 1 3) caus- 
es execution to continue at the beginning of the eight- 
word handler location 680-687 assigned to the highest- 
priority (lowest-numbered) asserted non-masked event. 
Because the VECTOR instruction 610 shown in FIG- 
URE 11 is normally used shortly after reactivation fol- 
lowing a WAIT instruction 654, there is reason to expect 
that at least one non-masked event flip-flop will be true 
(equal to one). If this were not the case, the context 
would not have become active. However, it is possible 
to include a vector at Base+64 words 688 for the case 
where no event bits are set. 

[0124] For the instruction set of the current embodi- 
ment, this vector pitch of eight words permits many han- 
dlers to fit entirely within the vector table requiring no 
branch while handling that event. For embodiments 
which provide a vector decode function of this type, the 
pitch may be chosen to achieve a balance between fit- 
ting the entire handler set into the vector table and leav- 
ing substantial amounts of control store unused due to 
the handler areas being much longer than is generally 
required. 

[01 25] From the above, it is apparent that the present 
invention provides a context controller for managing 
multitasking in a pracessor and a method of operating 
the same. In one embodiment, the context controller in- 
cludes: (1) an event recorder that records occurrences 
of events and (2) an encoder, associated with the event 
recorder, that, in response to a software instruction, pri- 
ority encodes bits corresponding to at least some of the 
events to generate therefrom an event-dependent vec- 
tor to allow the processor to branch as a function thereof. 
Vectoring is per-in stance of the vector decode software 
instruction, not per-event or per-context. 



Claims 

1. A context controller for managing multitasking in a 
processor, comprising: 

an event recorder that records occurrences of 
events; and 

an encoder, associated with said event record- 
er, that, in response to a software instruction, 
priority encodes bits corresponding to at least 
some of said events to generate therefrom an 
event-dependent veciorio allow said processor 
to branch as a function thereof. 

2. The context controller as recited in claim 1 wherein 
said encoder also generates said event-dependent 
vector from a selected one of: 

address information in said software instruc- 
tion, and 

address information in a register of said proc- 
essor. 



3. The context controller as recited in claim 1 or claim 
2 further comprising an event masker, associated 
with said event recorder and said encoder, that 
masks ones of said events to yield said at least 

5 some of said events. 

4. The context controller as recited in any of the pre- 
ceding claims wherein said event -dependent vector 
is selected from the group consisting of: 

10 

a direct branch, and 
an indirect branch. 

5. The context controller as recited in any of the pre- 
*s ceding claims wherein said event recorder is em- 
bodied in at least one flip-flop within said context 
controller 

6. The context controller as recited in any of the pre- 
20 ceding claims further comprising: 

a foreground task controller that activates con- 
texts corresponding to foreground tasks based 
on priority and in response to said events; and 
25 a background task controller that cyclicly acti- 

vates contexts corresponding to said back- 
ground tasks subject to activation of said con- 
texts corresponding to said foreground tasks. 

30 7. The context controller as recited in any of claims 1 
to 5 further comprising a background task controller 
that activates contexts corresponding to back- 
ground tasks based on numbers of instructions ex- 
ecuted by each of said background tasks. 

35 

8. A method of managing multitasking in a processor, 
comprising the steps of: 

recording occurrences of events; and 
4 o in response to a software instruction, priority 

encoding bits corresponding to at least some of 
said events to generate therefrom an event-de- 
pendent vector to allow said processor to 
branch as a function thereof. 

45 

9. The method as recited in claim 8 wherein said step 
of priority encoding comprises the step of also gen- 
erating saiu event-vjepenuent vector i rom a select- 
ed one of: 

50 

address information in said software instruc- 
tion, and 

address information in a register of said proc- 
essor. 

ss 

10. The method as recited in claim 8 or claim 9 further 
comprising the step of masking ones of said events 
to yield said at least some of said events. 
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11. The method as recited in any of claims 8 to 10 
wherein said step of priority encoding comprises the 
step of generating an event-dependent vector se- 
lected from the group consisting of: 

a direct branch, and 
an indirect branch. 



12. The method as recited in any of claims 8 to 11 
wherein said step of recording comprises the step 10 
of changing a state of at least one flip-flop within 
said context controller. 



13. The method as recited in any of claims 8 to 12 fur- 
ther comprising the steps of: is 

activating contexts corresponding to fore- 
ground tasks based on priority and in response 
to said events; and 

cyclicly activating contexts corresponding to 20 
said background tasks subject to activation of 
said contexts corresponding to said foreground 
tasks. 



14. The method as recited in any of claims 8 to 1 2 fur- 25 
ther comprising the step of activating contexts cor- 
responding to background tasks based on numbers 

of instructions executed by each of said background 
tasks. 

30 

15. A processor, comprising: 



an instruction decoder that decodes instruc- 
tions received into said processor and corre- 
sponding to a plurality of tasks; 35 
a plurality of register sets, corresponding to 
said plurality of tasks, that contain operands to 
be manipulated; 

an execution core, coupled to said instruction 
decoder and said plurality of register sets, that 40 
executes instructions corresponding to an ac- 
tive one of said plurality of tasks to manipulate 
ones of said operands; and 
a context controller as recited in any of claims 
1 to 7 for managing multitasking in said proc- 45 
essor. 



16. The processor as recited in claim 15 wherein said 
processor forms a portion of a general-purpose 
computer. so 
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FIG. 4A 



system IO.Controller — ^100 



HO 



/• BitStringB & 16 based on BiLString from Li 05 •/ 
syntype Cgroup - integer constants 0:3 endsyntype; 
syntype Cond = Integer constants 0:31 endsyntype; 
syntype CtxNum - Integer constants 0:7 endsyntype; 
syntype EventNum = Integer constants 0:7 endsyntype ; 
syntype InstAddr = Integer constants 0:65535 endsyntype; 
syntype Instruction = BitString16 endsyntype ; 
syntype Offset = Integer constants -128:127 endsyntype; 
syntype Vbase - Integer constants 0:1023 endsyntype; 

/* Exported from Context-Controller •/ 
remote asleep, csw, idle Boolean nodelay ; 
remote context CtxNum nodelay ; f* running context */ 
remote events BitString8 nodelay ; /• C-group 01 */ 
remote nctx CtxNum nodelay ; /• next context */ 
remote mask BitStringB nodelay ; /* Event Mask reg */ 

/* Exported from Data_Path_andJnterfcce_Resources */ 
remote slice Natural nodelay ; /• inst cycles per bg slice */ 
remote ien Boolean nodelay ; /• true for execute cycles •/ 



signal 

AckEv(CtxNum,EventNum) t 
Acklnst(EventNum), 
BcInst(Cond,Offset) f ClearCytCtxNum), 
ClearFG, CSaddrtfnstAddr), 
CSdota(Instnjction), CsLoad(CtxNum), 
CsStore(CtxNum), 
Event^CtxNum.EventNum), 
ExtEventtCbNum^ventNum), HfOsc, 
HwReset, lnitInst(CtxNum), 
InitSeq(CtxNum), LfOsc, 
LoadMosk(BitString8), Mr, Hf, 
Qr, Qf, Reset, SetCy(CtxNum) ( 
SetFG, Signallns^CtxNum.EventNum), 
SkpInst(Cgroup,Bit$tring8) t Sleep, 
VecInst(YbQ$e), Wait, Wake ; 



•104 



•102 
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FIG. 5 



ClkCctl 



. 140 



block Context. Controller 



110 




154 

s 

ClkPri 



141 

/ 
CctlSeq 



CsLood, 
CsStore, 
InitSeq 



160 
/ 



— 1 PriSeq 



142 

/ 
InstCcU 



162 
/ 
InstPri 



152 
\ 



10) 



|~Mr, ~| 
[ResetJ 



150- 



Mr, 

Mf, Qr. 

Reset, 

Wake 



EvenLSynchronizerl . ^Events 
(1.1) | [ExtEvent] 



124 

/ 

Eventsln 



Event. Prioritizer 

(i.O 



[Event] 



SyncEvents 

s 

166 



Acklnst, 

CtearfG, 

Initlnst, 

LoadMask, 

SetFG. 

Signallnst, 

Sleep, Wait 



[Event] 
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/ 
PriDP 



AckEv, 
CleorCy, 
j CsLoad, 
; CsStore, 
' SetCy 
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FIG. 6 



process Event_Synchronizer — ^150 

signal Endllork, ResetUark ; f\ 
signalset EndMark, ExtEvent, 
Mr, Reset, ResetMark ; 

del cf CtxNum ; 
del e$ EventNum ; 



id) 




/• This process synchronizes events originating outside of 
the DISC core to the leading edge of Ur. The assertion of 
each external event is indicated by an ExtEvent signal. The 
parameters of the signal provide the target context and 
event numbers. 

ExtEvent signals are saved in the process 1 input queue 
until receipt of signal Mr from the Clock_Generator block. 
The end of the input queue is nrwrked and all ExtEvent 
signals queued ahead of the EndMark are copied to Event 
signals and sent to the EvenLPnoritizer process, where 
they ore handled at the next Ur. •/ 



r 




Reset 
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FIG. 7A1 



process EvenLPrioritiier 1 52 



del act BitStringfi ; 
del c#, curBg CtxNum ; 
del e# EvenUlum ; 
del evMask, evStotus 

Arroy(CtxNum, BitString8) ; 
del fg BitString8 ; 
del k, i, prev CtxNum ; 
del sliceCount Natural ; 
del vol BitStringS ; 
del waited BitStringS ; 



-250 



signal ResetMark ; [\ 

signalset 
Acklnst, ClearFG, 
Event, Initlnst, 
LoodUask, 
Mr, Mf, Or, Reset, 
ResetMark, SetfG, 
Signoilnst, Sleep, 
Wait, Wake ; 



2! 



Imported ien Boolean ; 
imported slice Natural 



del exported asleep, csw, idle Boolean ; 
del exported ctx as context CtxNum ; 
del exported events, mask BitStringS ; 
del exported nctx CtxNum ; 



-252 



/* This process handles signals that alter event state, 
context activation state, or execution state (sleep, idle). 

While Running, events, Signal Instructions, and loading the 
Event Mask are handled at once; while Ack, Init, Sleep, 
Wait, and Set/Clear FG ore held on the process input 
queue until Mr At Mr of execute (ten-1 ) cycles, any 
queued instruction {max=1 /cycle) is processed, the context 
number, event flags (C-group l) and event mask values 
are updated to reflect a possible context switch, and the 
slice count is decremented if the running context is in 
background. At Or the activity flags are updated, then the 
highest priority active (fg) context, or current/next (bg) 
context is selected for execution at the next Mr, 
performing a context switch or going idle, starting at Mf, 
as appropriate. •/ 
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254 






act := 


0x80, 


256-- 


ctx := 


7. 




fg := 


OxFF. 






1 




events 


:= 0x00, 


258 — 


waited 


:= 0x00, 




mask 


:= OxOO, 



260- 



curBg := 0, 
sliceCount := 
import(slice) 



262 _ 
Inil 



I 



InitSeq(7) 



264 



^CIearCy(7) 



266- 



export 
asleep, csw, 
ctx, events, 



268 



via PriSeq 
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FROM FIG. 7A1 

A 




asleep 


:= false, 


csw := 


false, 


idle := 


false 





257 



evMask(0,l,2, 

3,4,5,6,7) 

:= 0x00, 
evStatus(0.1,2, 

3,4,5,6,7) 

:= 0x00 
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idle, 

mask, 

nctx 
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FIG. 7C 



process EvenLPrioritizer-^152 



3(4) 



Prioritize — 350 



T 



Acklnst 

'(•#) 



I 



360 



352 



Wait 



(evStatus(prev)) 
(•*) := 0 N54 



Qr 



V 



380 



I 



362 



I 



366 x > Sleep 



woited(prev):= 1 



AckEv 
(prev, e#) 



364 



I 



368 



asleep := true 



•356 



370- 



export asleep 



Kwoited(ctx) ) 
r ^382 

(=o) m 



372- 



•358 



Sleep 



oct(ctx) := 0, 
waited(ctx) := 0 K.584 



cf :=0 



V 



386 




act(c# := 
if (evMask(c#) 
and 



v 388 
else 



evStotus(c#)) = 0 
then actjcf) 
else 1 fi 

<S 

389 




•390 



394 
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FIG. 7D1 




process EvenLPrioritizer 

/ 

152 



4(4) 



k := k +1 




nctx := curBg, 
k := 0, 
1 := if 


1 











(act(ctx)=0) or 
fg(ctx)=0) then 
7 else ctx fi 



(true) 



I 1 v^426 

^o) \ oct(k) /(^T 



k < i 



(false) 







curBg : 




(cur8g 




mod 8 



not(fg(curBg)) 



428 
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(=QV\ and oct(curBg) /(-\) 



(false). 



curBg=nctx 
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nctx := curBg 



(true) 
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FIG. 7D2 



® 



idle := 
csw := 


true, 
true 






export idle, csw 



-442 



-444 



CsSove(ctx) 
via all 
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FROM FIG. 701 

A 





(true) S 


idle := 
csw := 


false, 
true 






export idle, csw 



idle 



-466 



-468 



CsLoad 
(nctx) 
via oil 
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Idle h^448 Running K-472 



^464 




(false) 




csw := 


true 






export csw 
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CsLood 
(nctx) 
via all 
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CsSave 
(ctx) 
via all 
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FIG. 13 



Initializotion Vectors 



670 — - 


Context 0 Initialization Vector 




0000 


671 — - 


Context 1 Initialization Vector 




0004 


672— 


Context 2 Initialization Vector 




0008 


673— 


Context 3 Initialization Vector 




000C 
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Context 4 Initialization Vector 




0010 


675— 


Context 5 Initialization Vector 




0014 


676— 


Context 6 Initialization Vector 




0018 


677— 


Context 7 Initialization Vector 
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